home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / asmutil / 80x0393.zip / ANTIANTI.TXT < prev    next >
Text File  |  1993-03-30  |  7KB  |  146 lines
  1. ;;
  2. ;;  Note by Uwe E. Schirm:
  3. ;;  This refers to the 'Anti Debugging Tricks' by Inbar Raz
  4. ;;  which is also found in the 80XXX Snippets as ANTIDBG.TXT
  5. ;;
  6.  
  7. Sun 24 Jan 93
  8. By: Michael Forrest
  9.  
  10.  
  11. Hi.  Here's release 1 of the Anti-Anti Debugging Tricks article.
  12.  
  13.  > In order to avoid tracing of a code, one usually disables the
  14.  > interrupt via the 8259 Interrupt Controller, addressed by 
  15.  > read/write actions to port 21h.
  16.  
  17. This is completely ineffective against Soft-ICE, which will still  break 
  18. in even when the KB interrupt is disabled.  I've never seen a case where 
  19. SI won't break into the code without your program actually reaching  out 
  20. and unplugging the keyboard.
  21.  
  22.  > Just as a side notice, the keyboard may be also disabled by
  23.  > commanding the Programmable Peripheral Interface (PPI), port 61h.
  24.  
  25. That code doesn't seem to do anything at all, even to debug.
  26.  
  27.  > This is quite an easy form of an anti-debugging trick. 
  28.  > All you have to do is simply replace the vectors of interrupts 
  29.  > debuggers use, or any other interrupt you will not be using or 
  30.  > expecting to occur.
  31.  
  32. Any  debugger  that's  worth  anything these days  works  in  a  virtual 
  33. machine.   That  means  that it keeps a  separate  interrupt  table  for 
  34. itself.  If you try to get to it, you'll get a general protection  fault 
  35. and  you'll crash when running under QEMM, Windows, OS/2, or  any  other 
  36. protected mode system.
  37.  
  38.  > This method involves manipulations of the interrupt vectors,
  39.  > mainly for proper activation of the algorithm. Such action, as
  40.  > exampled, may be used to decrypt a code (see also 2.1), using 
  41.  > data stored ON the vectors.
  42.  
  43. Again, debuggers keep separate interrupt tables for themselves.
  44.  
  45.  > This is a really nasty trick, and it should be used ONLY if you
  46.  > are ABSOLUTELY sure that your programs needs no more debugging.
  47.  
  48. It  IS a really nasty trick against a real-mode debugger like  Debug  or 
  49. something else available 5-10 years ago, but completely useless  against 
  50. Soft-ICE, TD386, or any other protected mode debugger.
  51.  
  52.  > This method simply retains the value of the clock counter, updated 
  53.  > by interrupt 08h, and waits in an infinite loop until the value 
  54.  > changes. This method is usefull only against RUN actions, not 
  55.  > TRACE/PROCEED ones.
  56.  
  57. That'll  defeat DEBUG and not much else.  Any other debugger has  a  key 
  58. that'll  break  into the code.  At that point, one could go  into  trace 
  59. mode or just replace the JZ 0109 with a series of NOP instructions.
  60.  
  61.  > This is a very nice technique, that works especially and only on 
  62.  > those who use Turbo Debugger or its kind. What you should do is 
  63.  > init a jump to a middle of an instruction, whereas the real address 
  64.  > actually contains another opcode.
  65.  
  66. I'm  not  really  sure what you're trying to  accomplish  here,  but  it 
  67. doesn't  do  much.  A simple "U CS:IP" or its equivalent  in  any  other 
  68. debugger  will  show the current instruction.  Anyway,  the  code  isn't 
  69. correct.
  70.  
  71.         IN     AL,21                            IN    AL,21h
  72.         MOV    AL,FF                            MOV   AL,0ffh
  73.         JMP    0108                             JMP   108
  74.         MOV    Byte Ptr [21E6],00    --->       MOV   BYTE PTR [21e6h],0cdh
  75.         INT    20                    --->       db    20h
  76.  
  77. You had an extra 00 in there.
  78.  
  79.  > This is a nice trick, effective against almost any real mode 
  80.  > debugger. What you should do is simply set the trace flag off 
  81.  > somewhere in your program, and check for it later.
  82.  
  83. Isn't  it  sort  of silly to be trying to  defeat  real-mode  debuggers?  
  84. That's sort of like putting locks on your back door to make sure  nobody 
  85. gets into your house while leaving the front door wide open.
  86.  
  87.  > This is a technique that causes a debugger to stop the execution 
  88.  > of a certain program. What you need to do is to put some INT 3 
  89.  > instructions over the code, at random places, and any debugger 
  90.  > trying to run will stop there.
  91.  
  92. Assembling  a NOP over the int 3 will get rid of the break.  Also,  many 
  93. debuggers (like Soft-ICE) can be set to not break on an INT 3.
  94.  
  95.  > This trick is based on the fact that debuggers don't usually use a
  96.  > stack space of their own, but rather the user program's stack space.
  97.  
  98. I'm not sure where you're getting this, but today's debuggers keep their 
  99. own  stack safely hidden away in a protected segment where your  program 
  100. can't  corrupt  it.   This  is also  only  effective  against  real-mode 
  101. debuggers  if  you  intend to run your entire  routine  with  interrupts 
  102. cleared, since most ISR's depend on your stack being there as well.
  103.  
  104.  > This is a nice way to fool Turbo Debugger's V8086 module (TD386). 
  105.  > It is based on the fact that TD386 does not use INT 00h to detect 
  106.  > division by zero.
  107.  
  108. Did  you actually try this?  It doesn't seem to have much effect at  all 
  109. on TD386.  Soft-ICE traces through it quite happily too.
  110.  
  111.  > Another way of messing TD386 is fooling it into an exception.
  112.  > Unfortunately, this exception will also be generated under any 
  113.  > other program, running at V8086 mode.
  114.  
  115. Yes,  and  in  a debugger it's _really_ easy to change  the  code  while 
  116. you're tracing through it to jump right over the offending  instruction.  
  117. All that you've done is eliminated compatibility with a lot of systems.
  118.  
  119.  > The first category is simply a code, that has been encrypted, 
  120.  > and has been added a decryption routine. The trick here is that 
  121.  > when a debugger sets up a breakpoint, it simply places the opcode 
  122.  > CCh (INT 03h) in the desired address, and once that interrupt is 
  123.  > executed, the debugger regains control of things.
  124.  
  125. ANY  decent  debugger these days will let you use  hardware  breakpoints 
  126. which  have nothing to do with INT 3 or any other instruction  replacing 
  127. existing  code.   They'll let you set breakpoints  wherever  you'd  like 
  128. without messing up encryption routines or self-modifying code.
  129.  
  130.  > This is an example of a self-tracing self-modifying code,
  131.  > sometimes called 'The running line'. It was presented by Serge
  132.  > Pachkovsky.
  133.  
  134. This is really the only effective measure in this document.  It defeated 
  135. every debugger I tried except for Soft-ICE.  Even under Soft-ICE it  was 
  136. hard to trace, since Soft-ICE has a quirk to it - it disables the  trace 
  137. flag  after each instruction.  It also includes fkey macros  though,  so 
  138. once  you realize what's going on, it's pretty easy to force it to  turn 
  139. the  trap flag back on before it executes the next instruction.  With  a 
  140. couple  of additional macros, I had it set up to trace through the  code 
  141. like nothing unusual was happening, except of course that the code I was 
  142. looking at kept changing, but that's another matter.
  143.  
  144. I had to change the routine you included since it doesn't handle  multi-
  145. byte instructions very well.
  146.